上篇介紹了 6 個可以擴大團隊成員能力的方法, 讓成員可以一邊工作一邊學習, 現在繼續介紹以下 6 個.

(7) 頻繁集成降低學習難度

學習應該是像嬰兒學步, 步伐不會太大, 並且還會左有搖擺. 同理, 在學習新的知識或是別人寫的程式, 每次的範圍不該太大, 這樣讓學習者壓力不會太大, 比較能夠吸收.

因此, 在持續整合的實踐上, 我們會建議每天要多次, 這樣開發人員每次新生或修改的代碼量不會太大, 別人要讀代碼所需要花費的代價也不會太大, 一方面這樣比較容易學習, 另一方面要找問題也比較簡單.

如果一天無法多次進行持續整合, 可以嘗試一天 2 次. 一次在半夜, 如果有人下班後加班, 改了代碼, 半夜時就先整合一下, 測試看看是否有些副作用, 大家來上班時, 第一時間就能確認這些修改所帶來的影響, 在第一時間確認沒問題. 第二次持續整合可以下午 4-5 點進行, 大家把今天撰寫的代碼 check-in, 如果都整合沒問題, 這樣大家也比較放心. 不會把整合的是拖到明天, 讓大家相互瞭解今天所改變的代碼是什麼.

(8) 聯合設計工作坊

在 Sprint Planning 會議的第二部分, 團隊需要去列出完成需要所需要做的任務 (Task). 在這個階段時, 有時候會遇到對某個需求, 不太清楚要如何開發, 需要一點設計和討論, 才能知道要如何列任務. 為了處理這樣的狀況, 你可以進行聯合設計工作坊.

聯合設計工作坊如何進行呢? 對於某個複雜的議題, 可以找相關有能力的成員一起來討論, 他們可能是同一個 feature team, 或者是來自於不同 feature team. 來自哪個團隊不重要, 重要他們可以出可行的做法. 當他們有初步的結論後, 他們帶回團隊, 和團隊分享討論的結果. 如果團隊有回饋, 也可以幫它帶到不同團隊中. 這樣各個團隊就有機會去互相學習, 可是又不會花太多時間.

去參加聯合設計工作坊的成員, 可能會每次都不相同, 因為這個工作坊在於解決問題, 所以要挑能打的人進來. 另外, 每次去參加這個工作坊的人數, 不一定要只有一個人, 或許每個團隊可以兩個, 讓某個不熟悉的成員, 直接加入討論, 來加速學習的步調.

(9) 元件守護者 (Component Guardians)

有些元件當初開發的團隊已經不存在, 或者已經散佈到各地, 因此, 當有團隊需要修改這些元件時, 他找不到原先團隊幫忙, 自己動手去改的機率就很大. 可以, 因為不熟的緣故, 這樣的修改風險就很大. 你不太可能假設這些元件有很多自動化測試保護, 只要重跑就可以確認你的修改是否有問題. 哪可以怎麼做呢?

你可以找原先很熟悉這些元件的人, 來當這個元件的守護者. 他的工作不是去幫別的團隊修改這個元件, 而是別的團隊要去修改這個元件時, 他來當導師, 指導這些團隊去修改, 或者是幫忙去檢視他們的設計或代碼. 這樣可能讓這些團隊學習這些元件的相關知識, 但是又有人指導他們, 避免他們歪樓. 此外, 我們也不會老是依賴某個人去維護某個元件, 讓這些技能或知識可以傳播出去.

(10) 架構代碼警察

有時候團隊有個很厲害的大大, 對於系統非常的了解, 並且開發功力也很強大. 有些公司內是架構師的角色. 這時候我們可以請他幫忙, 擔任架構代碼警察, 檢視大家 check-in 進去的代碼, 指導團隊成員去把程式寫好.

他不用每個人的代碼都去看, 可以針對比較複雜的部分, 新手所寫的程式, 或是不太熟悉那塊人所寫的代碼, 也就是風險較高的部分. 讓他幫忙看看是否這些代碼沒有大問題. 之前待過的公司有這樣的做法, 那位架構師抽樣去看, 還真的抓出不少問題, 也讓團隊成員透過這些的機制成長.

(11) 對於很專業的技能

有些很專業的部分, 不容易自學可以學會, 並且所花費的時間可能很久. 這時候很難叫新人或是不熟的人自己去寫. 這時候我們會利用幾種 practices 結合在一起使用.

首先, 先利用聯合設計工作坊, 讓懂得人帶著一些新手來討論, 一方面可以教學, 讓這個部分的知識可以多點人知道. 另一方面借助初學者的角度, 刺激原先懂的人打破成見. 接著, 讓懂得人和新手搭擋編程一起開發, 一方面新手學習程式架構, 另一方面也讓時程不會拖太久.

例如: Component D 的東西只有 Component D Team會. Feature Team A 和 Feature Team B 需要用到 Component D, 可是他們沒有人會, 並且 Component D Team 沒有足夠資源去完成那些功能給 Feature Team A 和 B 使用. 這時候 Feature Team A 和 B 可以派成員去跟 Component D Team 合作, 由 Component D team 的人主導來進行聯合設計工作坊. 之後 Component D team 出一些人和 Feature Team A 和 B 的成員搭擋編程. 一方面可以將 Component D 的知識傳播給 Feature Team A 和 B. 另一方面, 因為有 Feature Team A 和 B 的加入, 所以開發出來的 Component D 功能, 也能比較符合 Feature Team A 和 B 的需求. 比較不會過度設計, 或是設計出來方向錯太多.

(12) 實踐社團 (Community of Practice)

很多時候要推一個新東西, 需要靠有意願的人開頭, 這樣進展會比較容易些. 因此, 我們可利用社群的機制, 把對這新東西有興趣的人集合在一起, 讓他們想出方法來推廣, 這會比老闆指派去推行, 還要有效率的多.

我們來將一個大公司中利用社群來推行單元測試的故事. Google, 相信大家都知道的軟體公司, 他的能力是有目共睹的. 可是你知道他們如何推廣測試自動化嗎?

雖然他們工程師能力很強, 很要求 code review, 但是在 2001 年代左右, 他們是不做單元測試的. 那個年代很少人聽過這樣的觀念, 並且 Google 很講究 data driven, unit test 到底能帶來什麼改善, 很難用資料呈現, 因此 unit test 這件事很難搬到檯面上來推廣.

在 2005 年時, 有一群人成立了 Testing grouplet 來推廣測試自動化. 他們是自願來做的, 並非公司強迫, 所以這個組織才能撐得久, 他們花了 5 年時間, 讓測試自動化在公司內落地深根.

讓我們來看看他們做了什麼事呢? 下圖是 Testing Grouplet 所做過的實驗, 目前我沒時間一一介紹. 先挑以下三個重要的做法.

圖片來源: https://mike-bland.com/the-rainbow-of-death

A. Testing of the Toilet

人們常常會買一些測試書籍來看, 但是買回去之後通常就是放在床頭供著. 真的會去看得沒幾個. 另外, 公司常常做的是請一個講師來教大家, 可是能夠在這個短短 1- 2 天內記住所有東西, 不是件容易事. 之後還需要持續學習, 才能讓夠真的有效果.

因此在 2006 年一個 頭腦風暴會議, 他們想出這招來教大家學好測試: 在廁所貼測試的相關文章. 大約每週會有一篇文章, 在谷歌30 個辦公室中的數百個廁所都張貼. 讓他們在上廁所的短短 5 分鐘內, 學會一些測試的相關知識.

內容是自世界各地的志願者撰寫, 涵蓋不同編程語言和應用領域. 讓你不用花太多時間, 就能學會一些小技巧, 這些可能是來自不同團隊的經驗, 或者是不同工具的用法, 算是一種低代價, 短時間的, 讓大家學習的做法.

圖片來源: https://mike-bland.com/2011/10/25/testing-on-the-toilet.html

B. Test Certified

這個是 Bharat Mediratta 和 Nick Lesiecki 的心血結晶. 他們將測試自動化分成了五個層級

這個認證制訂出來, 可以有以下好處:

1. 告訴團隊要如何開始, 要從哪個方向開始.
2. 讓團隊自己決定要做多少
3. 公司可以從認證的程度, 知道測試自動化落實的狀況

C. Test Mercenaries

測試傭兵是 Google 內部的一個開發團隊, 由 SWE 所組成, 扮演內部自動化諮詢的角色. 成立時間是 從 2006 年末到 2009 年初, 致力於幫助開發團隊改進他們的測試實踐和代碼質量.

前面提到他們有設定測試認證的制度, 為了讓團隊願意採用, 他們需要有人協助, 因此測試傭兵這個團隊便會出馬, 幫助團隊落實測試認證 (Test Certified). 他們的目標, 是確保2009 年底所有團隊都能達到 level 3.

當我看完 Google 這段旅程, 真心覺得他們花了好多心思, 各種招式都使用, 才能讓 Google 這麼大的公司, 這些聰明優秀的人才買單. Google 都需要花 5 年才能有這樣的成就, 這如果沒有通過社群的力量, 一般的 task force 很難可以支持這麼久的.